[レポート] NET318: VPCを保護するためのベストプラクティス #reinvent

AWS re:Invent 2018

#Amazon VPC

#AWS

佐伯航

2018.12.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、佐伯です。

すでに日本に帰ってきていますが、去年もレポートした「Best Practices for Securing an Amazon VPC」の資料がSlideShareにアップロードされていましたので、読んでみました！なお、今年もワークショップ形式だったようですので、ハンズオン部分については省略しております。

スライド

[slideshare id=124110014&doc=best-practices-for-securing-an-45fdc54b-3531-41af-8086-4b4b19668203-980042629-181127005631]

概要

このインタラクティブなワークショップでは、安全なAmazon仮想プライベートクラウド（Amazon VPC）の設計と構築に関する実践的なアドバイスとガイダンスを提供します。ハンズオンアプローチを使用して、サブネット、セキュリティグループ、AWS PrivateLink、ネットワークACL、ルーティング、フローログ、サービスエンドポイントなどのAmazon VPC機能を使用します。また、大規模なインフラストラクチャを運用しているお客様をサポートしてきた経験に基づいて、VPCの設計と管理に関するベストプラクティスを共有しています。あなた自身のラップトップを持参することをお勧めします。

スピーカー

Corina Motoi - Solution Architect
Matt Johnson - Manager, Solutions Architecture, WWPS, AWS

Amazon VPCコントロールプレーンのセキュリティ保護

目的

VPCを管理する権限を設定し設定の変更を追跡/監査する方法を学ぶ

VPCの設定を保護するAWSサービス
- AWS Identity and Access Management(IAM)
変更を追跡/監査するAWSサービス
- AWS CloudTrail
- AWS Config

VPCを管理する権限の設定

AWS Identity and Access Management(IAM)

原則:

VPCリソースにアクセスするときに、最低限のアクセス権を許可する

次の項目を評価:

どのタイプのユーザーがVPCのリソースにアクセスするか?
ユーザーはどのVPCリソースにアクセスできるか?
ユーザーはどのようなタスクを実行する必要があるか?

最低特権アクセス:

アイデンティティ: ユーザ、グループ、ロール
アクセス管理: ポリシーとアクセス許可

IAMの仕組み

プリンシパル
- ユーザー、アカウント、サービスなどを指定
承認
- アクションレベルの許可
- リソースレベルの許可
- リソースベースの許可
- タグベースの許可
- リービスリンクロール
リソース

AWSドキュメント: IAM の詳細を理解します。 - AWS Identity and Access Management

IAMポリシーの構造

JSONドキュメント
ステートメント(パーミッション)の指定を含む
- プリンシパルが実行できるアクション
- どのリソースにアクセスできるか
複数のステートメントを記述でき、各ステートメントはPARC(Principal, Action, Resource, Condition)で構成される

AWSドキュメント: ポリシーとアクセス許可 - AWS Identity and Access Management

設定の変更を追跡/監査

AWS CloudTrail

AWS APIの呼び出しに関するイベントをキャプチャしてログに記録する
ユーザーとリソースのアクティビティの可視化に役立つ
セキュリティ及び運用上の問題の発見とトラブルシューティングに役立つ

AWS Config & AWS Config rules

AWS Config
- 継続的にAWSリソースの変更を記録
- AWSリソースの設定変更の時系列ビュー
- アーカイブと比較
AWS Config rules
- ベストプラクティスを強制する
- 不要な変更を自動的にロールバック
- 追加のワークフローをトリガー

VPCトラフィックフローのコントロール

目的

VPCトラフィック制御メカニズム、AWSの外部との接続、AWSサービスへのプライベート接続、またはマルチVPCアーキテクチャのために使用する方法を理解する。

VPCセキュリティの基本的なサービス
- Internet Gateway
- NAT Gateway
VPC接続パターンのベストプラクティス
- VPC Peering
- VPC Gateway Endpoint
VPCエンドポイントとAWS PrivateLinkを使った接続
- AWS PrivateLink

VPCトラフィックコントロールのメカニズムを理解する

サブネット
- アベイラビリティゾーン固有のもので、パブリックまたはプライベートに設定できる
セキュリティグループ
- インスタンスはまたENIに対して仮想ファイアウォールとして動作し、インバウンドおよびアウトバウンドトラフィックを制御する
- 相互参照することができる(同一リージョン内)
ルートテーブル
- ルートと呼ばれる一連のルールが含まれており、ネットワークトラフィックがどこに向かうかを判断するために使用
- VPCの各サブネットはルートテーブルに関連付けられている必要がある
ネットワークACL(NACL)
- VPCのセキュリティオプション
- ひとつまたは複数のサブネットに出入りするトラフィックを制御する

セキュリティグループとネットワークACLの比較

セキュリティグループ	ネットワークACL
インスタンスレベルで動作する	サブネットレベルで動作する
許可ルールのみ設定可能	許可および拒否ルールを設定可能
ステートフル(戻り通信は自動で許可される)	ステートレス(戻り通信の許可ルールを設定する必要がある)
全てのルールが評価される	ルール番号の低い順に評価され一致するルールがあれば以降の評価は行わない
インスタンスに明示的に関連付けた場合に適用される	関連付けられたサブネット内の全てのインスタンスに自動的に適用される

セキュリティグループとネットワークACLはリンクローカルアドレス (169.254.0.0/16) またはAWS予約済みIPアドレスとやり取りされるトラフィックをフィルタリングしません。AWS予約済みアドレスは、サブネットの最初の4個のIPアドレス (VPCのAmazon DNSサーバーアドレスを含む)

AWSドキュメント: セキュリティ - Amazon Virtual Private Cloud

ネットワークACLを使用する理由

役割の分離
- 異なるIAMアクションにより、セキュリティグループとネットワークACLの管理を分離できる
明示的な拒否ルールを指定できる
- 特定のIPアドレス/ポートをブラックリスト形式で登録できる
接続追跡されたトラフィックフローを切断する
- セキュリティグループを削除した際、そのトラフィックがすぐに中断されるようにする場合にネットワークACLを使用する(*)

*接続追跡

落とし穴

セキュリティグループは同一サブネットであってもインスタンス間の通信を暗黙的に許可しない
セキュリティグループのルールにプライベートアドレスを設定した場合は、プライベートアドレス宛の通信に対して機能する
- VPC内からパブリックIPへのアクセスは送信元がパブリックIPアドレスとなる
ELBを使用する際のネットワークACLでの注意
- ELBからバックエンドへのヘルスチェック通信を許可する
- ELB通信は同一サブネットであってもVPCルーターを経由する

AWSの外部とのトラフィックコントロール

インバウンド通信

アウトバウンド通信

オンプレミスとの接続オプション

AWSの内部とのトラフィックコントロール

AWSサービスへのプライベート接続

ユースケース
- VPCへのDX/VPN接続のみを使用するシナリオ
- VPCからインターネットへの出力がない(したがってAWS APIエンドポイントをコールできない)
ベストプラクティス
- VPCからの発信トラフィックのみを許可することで攻撃対象を減らす
これをサポートするサービス
- VPCエンドポイント

VPCエンドポイント

インターネットゲートウェイ、NATゲートウェイがない場合、パブリックIPアドレスが必要となる。

VPCゲートウェイエンドポイント
- VPC内からプライベートネットワークでS3とDynamoDBへのアクセスが可能
- IAMベースアクセスコントロール
VPCインターフェイスエンドポイント(AWS PrivateLink)
- VPC内からプライベートIPアドレスで指定したAWSサービス、またはユーザーのエンドポイントにアクセス可能
- セキュリティグループでのアクセスコントロール

VPCゲートウェイエンドポイントのアクセスコントロール

堅牢なアクセス制御
- ルートテーブルアソシエーション
- リソースポリシー(S3エンドポイント)
- VPCエンドポイントポリシー
- セキュリティグループ内でプレフィックスリスト指定

VPCエンドポイントポリシー

VPCエンドポイントポリシーはエンドポイントを作成または変更するときにアタッチできるIAMリソースポリシーです
エンドポイントポリシーはIAMユーザーポリシーやサービス固有のポリシー(S3バケットポリシーなど)に代わるものではない
複数のポリシーをエンドポイントに追加することはできない

AWSドキュメント: https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-endpoints-access.html#vpc-endpoint-policies

プレフィックスリストとセキュリティグループ

ターゲットへの論理的なルート
S3プレフィックスリストは、S3で使用されるパブリックIP範囲を表す
セキュリティグループのルールとして指定可能

AWSドキュメント: ゲートウェイエンドポイントのルーティング

VPCインターフェイスエンドポイント(AWS PrivateLink)のアクセスコントロール

インターフェイスエンドポイントはVPC内に作成される
- アベイラビリティゾーンごとにENIが作成される
- VPCサブネット内のIPアドレスがアサインされる
- DX, VPN, インターリージョンVPCピアリングからもアクセス可能
プライベートDNS名のサポート
ENIにセキュリティグループを関連付け可能
現在サポートしているサービス
- インターフェイス VPC エンドポイント (AWS PrivateLink) - Amazon Virtual Private Cloud
- 他のAWSアカウントが提供しているサービス
- AWS Marketplaceパートナーサービス

マルチVPCアーキテクチャでのトラフィックコントロール

ユースケース
- ２つ以上のVPCをピアリングしてリソースへのアクセスを提供する
- ひとつのVPCをピアリングして集中型のリソースにアクセスする
ベストプラクティス
- "Minimize blast radius for users and networks"
- ユーザーとネットワークへの影響範囲を最小限に留める?
これをサポートするサービス
- VPCピアリング
- AWS PrivateLink

VPCピアリング

ふたつのVPC間のネットワーク接続
以下のピアリング接続を行うことが可能
- 同じAWSアカウント内のVPCと
- 他のAWSアカウントのVPCと
- 別のリージョンのVPCと
Amazon VPCのインフラストラクチャを使用している
- ボトルネックはない
- 単一障害点はない

AWS PrivateLink

SaaSサービスを安全に提供するのに最適
テナント:
- シングルテナントモード:すべてのクライアント/顧客用にPrivateLink用のNLBを作成
- マルチテナントモード:すべてのクライアント/顧客が同じPrivateLinkのNLBを使用
エンドポイントにリージョンDNSホスト名とゾーンDNSホスト名がある

AWS PrivateLinkの役立つ情報

どうやってエンドポイントへのトラフィックを区別するのか?
- アカウント/パスワード/セキュリティトークンをアプリケーションレベルで使う
- NLBを分割、ターゲットで違うリスナーポートを使用する
- ProxyProtocalV2プリアンブルを有効にする
一方向のみのトラフィックをサポート
TCPのみサポート、UDPはサポートしていない。

VPCピアリングとAWS PrivateLinkの比較

VPCモニタリングと自動修復

目的

VPC関連の監視ツールと、それらを使用してセキュリティ違反を検出および修復する方法について説明します。

VPCモニタリングの役割はなにか?

IPトラフィックフローの監視
悪意のある行為や許可されていない行為の検出
自動修復のトリガー

VPCモニタリングのツールとサービス

VPCフローログ

VPC内のネットワークインターフェイスで送受信されるIPトラフィックをキャプチャする。

ユースケース
- 過度に制限的なセキュリティ制御の診断
- インスタンスに到達するトラフィックの監視
- 特定種類のトラフィックに応じてトレンドを特定しアラームを作成

VPCフローログのフォーマット

AWSドキュメント: フローログレコード

VPCフローログの役立つ情報

トラフィックがセカンダリIPアドレスを持つENI宛に送信されても、フローログの送信先IPアドレスはプライマリIPアドレスが表示される
フローログの API アクション (ec2:*FlowLogs) は、いずれもリソースレベルのアクセス権限をサポートしていない
以下のトラフィックはキャプチャされない
- Amazon DNSサーバー宛のトラフィック
- Windowsライセンスアクティベーションサーバー宛のトラフィック
- インスタンスメタデータ用の169.254.169.254宛のトラフィック
- DHCPリクエストとDHCPレスポンスのトラフィック
- デフォルトVPCルーターの予約済みIPアドレスへのトラフィック

Amazon GuardDuty

インテリジェントな継続的なセキュリティ監視と脅威検出、完全に管理された統合脅威インテリジェンス、異常検出、および機械学習サービスです。

Amazon GuardDutyの脅威検出タイプの詳細

AWSドキュメント: GuardDuty のアクティブな結果タイプ - Amazon GuardDuty

Amazon GuardDutyの役立つ情報

GuardDutyがログタイプのいずれかを処理するためにロギングをオンにする必要はありません。
現在のところ、ユーザーはDNSログに直接アクセスすることはできず、実際にはGuardDutyはこれらのログを監視する唯一の手段です。
GuardDutyは関連するサービスから直接取得するため、すべてのログはバックエンドですべて実行されます。したがって、アーキテクチャーの変更、エージェントの不要、アカウントのパフォーマンスへの影響は不要です。

Amazon CloudWatchの役立つ情報

CloudWatchはさまざまな機能を提供します
- メトリクス
- ダッシュボード
- ログ
- イベント
- アラーム
CloudWatch Logsはさまざまなメリットを提供します
- ログデータの有用な集約ポイント
- データを他のサービスにプッシュする機能
- サードパーティのサービスとの統合

VPCモニタリングツールを使ってセキュリティ侵害を検出および修復する方法

CloudWatch Events概念の役立つ情報

APIアクティビティによって駆動
概念
- イベント: AWS環境における変化を示す
- 他のAWSサービスによって生成される
- スケジュールによって生成される
- カスタムアプリケーションレベルのイベントによって生成される
- ターゲット: イベントを処理する対象
- ターゲットには例えばAWS Lambda、Kinesis Streams、Step Functionsなどを設定することができる
- ルール: 一致した受信イベントを検出し、イベント処理のためにターゲットに振り分ける
- ひとつのルールで複数のターゲットを指定できる
- 並列に処理される
Amazon CloudWatch Events busにより、組織内または組織間でCloudWatch Eventsを管理可能